Mobile Game Networking Essentials : Multiplayer Game Basics & Network Game Problems and Solutions

Multiplayer Game Basics

If you’ve been fortunate enough to play a multiplayer network game with your friends, you already know how much fun it can be. In many ways, outwitting a real person is much more fun than competing against a computer player. The reality of going head-to-head with another person can change the whole perspective of a game. I have yet to see a single-player game that evokes the same level of emotion and excitement as is generated from the human factor in multiplayer games.

There are endless possibilities for multiplayer games involving both cooperation and competition among human players. Regardless of the scenario, when real people are involved, a certain synthesis of ideas and reactions takes place that just isn’t possible with computer players. It’s then up to game designers like you and me to chart the course and dream up new ways for people to interact with each other through games. Now consider the uniqueness of being able to play a multiplayer game on a mobile phone over a wireless network connection from anywhere. This is what many of us have been waiting for in the “wireless revolution” we’ve been hearing so much about for the past few years.

Before you get into the design strategies for network games, it’s important to understand the fundamental types of network games. The communication design can be affected dramatically by the way that game play progresses, which is determined by the type of game. Mobile network games can be generally broken down into two types: turn-based and event-based. Most games should easily fall into one of these two categories.

Turn-Based Games

Turn-based games are games in which each action in the game is based on a player’s turn. The classic checkers, chess, and Connect 4 games are good examples of turn-based games because you are allowed to make a move only when it is your turn. Sure, you are free to think about your move during the other player’s turn, but in the context of the game you can take action only during your turn.

Most turn-based games are board games or card games, or simple games played on paper such as Tic-Tac-Toe. Although they have a much slower pace than action games, turn-based games are very popular and well suited for networking.

Knowing that turn-based games revolve around whose turn it is, the network communication design is greatly simplified. Only one player can interact with the game at a time. Even though multiple players are technically playing the game, only one player is allowed to make a move at a time. The other players must wait their turns before they can do anything. In this way, the game can be designed so that all the players are in a wait state until it becomes their turn. In a two-player game such as Connect 4, the turns just move back and forth between the players.

Event-Based Games

Event-based games are games that are dictated by input events that can occur at any time. Event-based games are much more open-ended than turn-based games. In an event-based game, any player can interact with the game at any time, resulting in an input event. The flow of the game is dictated by the input events rather than turns. As a matter of fact, there is no concept of a “turn” in an event-based game. Event-based games include basically all games that don’t revolve around turns; examples range from first-person shoot-em-ups such as the popular Halo and Doom series to strategy simulators such as Age of Empires. In the network modes of these games, any player can act independently of any other players, generating anywhere from no events to a massive flood of events.

If you haven’t suspected, the communication design for event-based games is much more complex and difficult to implement than that for turn-based games. More importantly, event-based game communication typically requires a much wider bandwidth, because more information is usually being transmitted. It’s probably safe to say that each different event-based game you create will have a unique solution because there are so many trade-offs to be made in regard to determining the best way to design the network communication logic. In a game such as Halo 2 or Doom 3, think about how many things are going on—and even more important, notice how quickly things are happening. Any change in the game from one player’s perspective must be communicated to all the other players in some form.

An event-based game never “allows” the players to do anything, as in turn-based games. The game just sits back and waits for the players to generate input events. Players can generate these events as often or as seldom as they want, fully independent of the other players. This is what enables you to patiently wait behind a corner while another player runs by haphazardly at full speed. Some people never learn!

Network Game Problems and Solutions

Now that you know which type of network games you are dealing with, let’s look at some of the common problems you will encounter in a mobile network game design. The overriding concern to be dealt with in designing network games is maintaining synchronization. Synchronization refers to how multiple game instances running on different phones maintain the same game state information. Remember that each player is running a separate instance of the game, but the overall goal is to make each of these different instances function logically as one game. All the internal data structures modeling the game’s state should match exactly on each player’s system.

You can best understand this concept by looking at an example of what can happen when synchronization is lost. Suppose that two players are playing a network adventure game similar to one of the games in the popular Diablo series. As they are walking along together, they run across a demon. Player 1 is a little more assertive and starts fighting the demon. Player 2 is low on energy and decides to just sit in the shade and watch. When Player 1 finishes off the demon, Player 2 somehow must be notified, and not just as a matter of convenience; any change in the game that potentially can affect other players must be communicated to them.

Another common problem in regard to synchronization involves using random values in games. It is fairly common for games to place some objects randomly when a game starts, such as treasure or even monsters. Sometimes games use random events just to make things vary a little from game to game. In network games this creates big problems unless each game instance uses the exact same random values as all the other instances. It would totally blow the synchronization for each game to have things going on randomly with respect to each instance. The point here is that many seemingly insignificant things, such as generating random numbers, can cause major headaches in a network game environment.

Now that you understand the problems, let’s move on to some solutions. There are many different approaches to designing network game communications, and they all must somehow address the problem of keeping each player’s instance of the game synchronized with all others. You’re going to focus on two basic types of network game synchronization strategies: state synchronization and input synchronization.

State Synchronization

State synchronization is a communication method by which each game instance communicates its current state to the other instances. The state synchronization method is very robust because there is no chance for information loss; everything regarding the current state of the game is sent to the other instances. In a two-player space battle game, for example, the position and speed of all the planets, asteroids, ships, and bullets would be sent as the current state of the game.

Sounds good so far. But what about a more complex game, such as a role-playing adventure game with entire virtual worlds with which the players constantly are interacting? Sending the state of the entire game starts looking a little more difficult because of the vast amounts of information required to model the game state. And don’t forget about the bandwidth limitation you learned about earlier, which keeps you from being able to send loads of information between mobile phones. Knowing this, it’s easy to see that state synchronization is a fairly messy network communication solution. Although state synchronization is functionally a very solid network solution, technically it’s not always feasible.

Input Synchronization

Input synchronization is a communication method in which each game communicates the input events of its player to the other game instances. Using input synchronization, each time a player generates input events, such as pressing keys, the game broadcasts these events to the other games. If you think about the space battle game example from before, rather than send the state of all the objects, the game just sends the key input events generated by the player. Each game then handles each remote (virtual) input from the other games in a similar manner as it handles its own local player’s input.

There has to be a catch, right? Of course there’s a catch! Input synchronization works fine as long as all the changes in the game are dictated solely by the players’ inputs. Practically speaking, this rarely is the case except in very simple games. There are usually random effects in a game, such as placement of background objects. These random effects wreak havoc on games relying on input synchronization because they aren’t affected by player input and therefore are never communicated between games.

If you happen to have a game in which the entire play flow is dictated by player input, input synchronization is for you. Otherwise, you’ll have to come up with another solution. Can you think of any games that are dictated entirely by user input? Give up? It ends up that most turn-based games are driven completely by user input. So you usually can implement network support for turn-based games by using input synchronization.

A Hybrid Solution

Now that I’ve painted a pretty bleak picture of network game design, I’ll let you in on a practical reality in mobile network game design: You usually will have to use some combination of the two methods mentioned. This hybrid solution would include elements of both state and input synchronization. Using the space battle game example one more time, you could send the user inputs back and forth using input synchronization, and then use state synchronization to send random events such as initial meteor positions. You still don’t necessarily need to transmit the entire state of the game, just the aspects of the game state that can’t be figured out by each instance on its own. In other words, random events need to be transmitted to each game instance.

If you run across a gaming scenario that doesn’t fit well within any of these approaches, you might figure out a communication technique of your own to add to or replace one of these. Network gaming is a unique area of game programming that leaves room for very few general techniques. You usually have to come up with hybrid solutions that draw on what you’ve learned, combined with new ideas you dream up along the way.